Two major types of Programming Language Runtimes are created by interpreters and compilers. Interpreters usually execute a software program slower than compilers due to translation of source code expressed in a high-level computer language into machine code (also called “object code” or “native code”), one instruction at a time, during execution of the software program in a computer (“run-time computer”). On the other hand, compilers can generate machine executable native code from source code ahead of time (AOT), typically in a different computer (“build computer”). Compilers are typically more complicated to develop and support than interpreters, but compiler-generated object code can execute faster than interpretation of source code in a procedural language.
Structured query language (SQL) is a declarative language which is not procedural. Statements (also called queries) written in SQL describe what should be done, without describing how a relational database should be accessed. Hence, in prior art, database statements expressed in SQL are typically received and then interpreted by run-time computers (“database servers”), instead of being compiled ahead of time in a build computer that generates machine code of a relational database management systems (RDBMS). During interpretation, an engine in the RDBMS executing in a database server that receives an SQL statement, parses the SQL statement, i.e. does so at database run time.
A parsed SQL statement and associated information (such as bind variable values) may be stored in a private SQL area (also called “cursor”) in a memory of the database server, e.g. as described in Chapter 14 entitled “Memory Architecture” of the book Oracle® Database Concepts, 11g, Release 2 (11.2), published October 2010, E16508-05 that is incorporated by reference herein in its entirety. The RDBMS engine then prepares the parsed SQL statement for execution, by creating a plan (“execution plan”) to allocate local resources (such as buffers and registers). Such an execution plan may also be stored in the just-described cursor (“database cursor”), and used by the RDBMS engine, to execute the SQL statement in the database server. A database cursor may hold information identifying one or more sequences of machine code in the RDBMS engine (such as a function for expression evaluation or another function for key comparison). The one or more sequences of machine code which are identified in a specific database cursor are portions of the RDBMS, also identified (and shared) in execution plans of other database cursors for other database statement(s).
Creation and execution of an execution plan at database run time enables a database server to process any new SQL statement that is dynamically received. Such flexibility in processing any SQL statement imposes a performance penalty in the database server, because each SQL statement must be parsed in the database server after its receipt, and only then executed. The performance penalty can be reduced by re-using an execution plan of a parsed SQL statement (in the database cursor), to process any subsequent occurrences of that same SQL statement when identical SQL statements are issued by multiple users and/or applications.
A parsed SQL statement in an execution plan in a cursor is normally executed by an SQL interpreter which incurs overhead (“interpretive overhead”). Although a compiler can generate machine code that lacks interpretive overhead, the SQL statement to be executed is not known until database run time. Compilation of a SQL statement to machine code after the SQL statement is received imposes its own penalty, which can reduce system throughput.
To the knowledge of the inventors of the current patent application, the prior art does not appear to disclose or render obvious the inventors' generation of machine code for a database statement by specialization of interpreter code, as follows.